Attifunel process req test description added#679
Conversation
attifunel
requested review from
PandaeDo,
aschemmel-tech,
masc2023 and
pahmann
as code owners
|
The created documentation from the pull request is available at: docu-html |
| Requirements analysis is a testing technique where tests are designed based on the | ||
| requirements assigned to the software element under test (component, module, unit etc.). |
There was a problem hiding this comment.
| Requirements analysis is a testing technique where tests are designed based on the | |
| requirements assigned to the software element under test (component, module, unit etc.). | |
| Requirements analysis is a test derivation technique where tests are designed based on the | |
| requirements assigned to the software under test (unit, component, feature, etc.). |
There was a problem hiding this comment.
I would still keep "SW element" as it's the most generic definition in ISO 26262 of any hierarchical piece of SW
There was a problem hiding this comment.
Agree, but I would still see it as a test derivation technique.
| Requirements should always be tested against their "nominal" behaviour: i.e. "if input | ||
| x = A, the output y of SW component X shall be equal to b". This leads to a test case | ||
| injection value x = A and verifying that output y = B. "Negative" testing technique should | ||
| be also considered: i.e. testing what happens when input x = B (if not already specified | ||
| in other requirements). |
There was a problem hiding this comment.
| Requirements should always be tested against their "nominal" behaviour: i.e. "if input | |
| x = A, the output y of SW component X shall be equal to b". This leads to a test case | |
| injection value x = A and verifying that output y = B. "Negative" testing technique should | |
| be also considered: i.e. testing what happens when input x = B (if not already specified | |
| in other requirements). | |
| Requirements should always be tested against their "nominal" behaviour: i.e. "if input | |
| x = A, the output y of SW component Z shall be equal to B". This leads to a test case | |
| injection value x = A and verifying that output y = B. "Negative" testing technique should | |
| be also considered: i.e. testing what happens when input x = B (if not already specified | |
| in other requirements). |
There was a problem hiding this comment.
I would also change the negative case input to something different than B...
| Note that requirement-based testing derivation is typically covered by other techniques | ||
| mentioned here, such as Boundary Values, Equivalence Classes, Fuzzy Testing, Interface | ||
| Testing and Fault Injection. |
There was a problem hiding this comment.
| Note that requirement-based testing derivation is typically covered by other techniques | |
| mentioned here, such as Boundary Values, Equivalence Classes, Fuzzy Testing, Interface | |
| Testing and Fault Injection. | |
| Note that requirement-based testing derivation is typically covered by other techniques | |
| and methods mentioned here, such as Boundary Values, Equivalence Classes, and Fuzzy Testing. |
Interface testing is verification method, but according to the iso not a derivation technique. Same holds true for Fault injection.
There was a problem hiding this comment.
Mhmhm... I have this opinion that ISO 26262 makes a bit of mixed bag there by mixing "derivation methods" and "techniques". I wanted to stay generic speaking of "techniques" without derivation, but maybe this causes confusion?
There was a problem hiding this comment.
My point of concern is where it says typically covered by do you mean it gets extended by or enhanced by? With the current wording it sounds much more like being included in the other techniques.
2 participants
Added requirement method with description